針對 Windows Server 軟體定義的網路堆疊進行疑難解答

本指南會檢查常見的軟體定義網路 (SDN) 錯誤和失敗案例,並概述使用可用診斷工具的疑難解答工作流程。 如需 SDN 的詳細資訊,請參閱 軟體定義網路

適用於:Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI 21H2 和 20H2 版

錯誤類型

下列清單代表在 Windows Server 2012 R2 中從市場內生產部署 (HNVv1) 最常看到的問題類別,並且在許多方面與 Windows Server 2016 HNVv2 中與新的軟體定義網路 (SDN) Stack 相同的問題類型一致。

大部分的錯誤都可以分類為一小組類別:

  • 無效或不支持的設定

    使用者以不正確或無效的原則叫用 NorthBound API。

  • 原則應用程式中的錯誤

    網路控制站的原則未傳遞至 Hyper-V 主機、所有 Hyper-V 主機上的延遲或不是最新狀態,例如,在即時移轉) 之後 (。

  • 設定漂移或軟體錯誤

    導致封包捨棄的數據路徑問題。

  • 與 NIC 硬體/驅動程式或底層網路網狀架構相關的外部錯誤

    行為錯誤的工作卸除 (例如 VMQ) 或重迭網路網狀架構 (設定錯誤,例如 MTU)

    本疑難解答指南會檢查這些錯誤類別,並建議可用來識別和修正錯誤的最佳做法和診斷工具。

診斷工具

在討論針對每種錯誤類型的疑難解答工作流程之前,讓我們先檢查可用的診斷工具。

若要使用網路控制器 (控制路徑) 診斷工具,您必須先安裝 RSAT-NetworkController 此功能並匯入 NetworkControllerDiagnostics 模組:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

若要使用 HNV 診斷 (資料路徑) 診斷工具,您必須匯入 HNVDiagnostics 模組:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

網路控制器診斷

這些 Cmdlet 記載於 TechNet 的 網路控制器診斷 Cmdlet 中。 它們可協助識別網路控制器節點之間的控制路徑,以及網路控制站與 Hyper-V 主機上執行的 NC 主機代理程式之間的網路原則一致性問題。

Debug-ServiceFabricNodeStatusGet-NetworkControllerReplica Cmdlet 必須從其中一個網路控制站節點虛擬機執行。 所有其他 NC 診斷 Cmdlet 都可以從任何可連線至網路控制站的主機執行,且位於網路控制站管理安全組中, (Kerberos) 或可存取 X.509 憑證來管理網路控制站。

Hyper-V 主機診斷

這些 Cmdlet 記載於 TechNet 的 Hyper-V 網路虛擬化 (HNV) 診斷 Cmdlet 中。 它們可協助識別租使用者虛擬機 (東部/西部) 和透過 SLB VIP (北/南) 輸入流量之間的數據路徑問題。

Debug-VirtualMachineQueueOperationGet-CustomerRouteGet-PACAMapping、、Get-ProviderAddressGet-VMNetworkAdapterPortIdGet-VMSwitchExternalPortIdTest-EncapOverheadSettings 都是可從任何 Hyper-V 主機執行的本機測試。 其他 Cmdlet 會透過網路控制站叫用資料路徑測試,因此需要如上所述存取網路控制站。

GitHub

Microsoft/SDN GitHub 存放庫有許多以這些內建 Cmdlet 為基礎的範例腳本和工作流程。 特別是,診斷腳本可以在 [ 診斷 ] 資料夾中找到。 提交提取要求,協助我們參與這些腳本。

針對工作流程和指南進行疑難解答

[Hoster]驗證系統健康情況

在數個網路控制站資源中,有一個名為 Configuration State 的內嵌資源。 設定狀態提供系統健康情況的相關信息,包括網路控制器設定與在 Hyper-V 主機上執行) 狀態的實際 (之間的一致性。

若要檢查組態狀態,請從任何連線到網路控制站的 Hyper-V 主機執行下列命令。

注意事項

參數的 NetworkController 值應該是 FQDN 或 IP 位址,根據為網路控制站建立的 X.509 >憑證主體名稱。

Credential只有當網路控制器使用 Kerberos 驗證時,才需要指定 參數, (VMM 部署) 中一般的情況。 認證必須適用於網路控制器管理安全組中的使用者。

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

範例組態狀態訊息如下所示:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

注意事項

系統中有一個錯誤,SLB Mux 傳輸 VM NIC 的網路介面資源處於失敗狀態,並出現錯誤「虛擬交換器 - 主機未連線到控制器」。 如果 VM NIC 資源中的 IP 組態設定為來自傳輸邏輯網路 IP 集區的 IP 位址,可以放心地忽略此錯誤。

系統中的第二個錯誤是閘道 HNV 提供者 VM NIC 的網路介面資源處於失敗狀態,並出現錯誤「虛擬交換器 - PortBlocked」。 如果 VM NIC 資源中的 IP 組態依設計設定為 null (,也可以安全地忽略此錯誤) 。

下表顯示根據觀察到的組態狀態所要採取的錯誤碼、訊息和後續動作清單。

代碼 訊息 動作
Unknown 未知的錯誤
HostUnreachable 無法連線到主電腦 檢查網路控制站與主機之間的管理網路連線
PAIpAddressExhausted PA IP 位址已用盡 增加 HNV 提供者邏輯子網的 IP 集區大小
PAMacAddressExhausted PA Mac 位址已用盡 增加 Mac 集區範圍
PAAddressConfigurationFailure 無法將PA位址配色到主機 檢查網路控制站與主機之間的管理網路連線。
CertificateNotTrusted 憑證不受信任 修正用於與主機通訊的憑證。
CertificateNotAuthorized 憑證未獲授權 修正用於與主機通訊的憑證。
PolicyConfigurationFailureOnVfp 設定 VFP 原則失敗 這是運行時間失敗。 沒有明確的因應措施。 收集記錄。
PolicyConfigurationFailure 將原則推送至主機時失敗,因為 NetworkController 中的通訊失敗或其他錯誤。 沒有明確的動作。 這是因為網路控制器模組中的目標狀態處理失敗。 收集記錄。
HostNotConnectedToController 主機尚未連線到網路控制站 未在主機上套用埠配置檔,或無法從網路控制站連線到主機。 驗證 HostID 登錄機碼是否符合伺服器資源的實例識別碼
MultipleVfpEnabledSwitches 主機上有多個已啟用 VFp 的交換器 刪除其中一個交換器,因為網路控制站主機代理程式只支援一個已啟用 VFP 擴充功能的 vSwitch
PolicyConfigurationFailure 無法推送 VmNic 的 VNet 原則,因為發生憑證錯誤或連線錯誤 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機) 的 FQDN。 也請確認與網路控制站的主機連線
PolicyConfigurationFailure 無法推送 VmNic 的 vSwitch 原則,因為發生憑證錯誤或連線錯誤 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機) 的 FQDN。 也請確認與網路控制站的主機連線
PolicyConfigurationFailure 無法推送 VmNic 的防火牆原則,因為發生憑證錯誤或連線錯誤 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機) 的 FQDN。 也請確認與網路控制站的主機連線
DistributedRouterConfigurationFailure 無法在主機 vNic 上設定分散式路由器設定 TCPIP 堆疊錯誤。 可能需要在報告此錯誤的伺服器上清除PA和DR主機 vNIC
DhcpAddressAllocationFailure VMNic 的 DHCP 位址配置失敗 檢查靜態 IP 位址屬性是否已在 NIC 資源上設定
CertificateNotTrusted
CertificateNotAuthorized
因網路或憑證錯誤而無法連線到 Mux 檢查錯誤訊息碼中提供的數值碼:這會對應至 winsock 錯誤碼。 憑證錯誤是細微 (例如憑證無法驗證、憑證未獲授權等。)
HostUnreachable MUX 狀況不良 (常見的案例是 BGPRouter 已中斷連線) RRAS (BGP 虛擬機) 或 Top-of-Rack (ToR) 參數上的 BGP 對等互連無法連線或無法成功對等互連。 檢查軟體 Load Balancer 多任務器資源和 BGP 對等 (ToR 或 RRAS 虛擬機上的 BGP 設定)
HostNotConnectedToController SLB 主機代理程式未連線 檢查 SLB 主機代理程式服務是否正在執行;請參閱 SLB 主機代理程式記錄 (自動執行) 的原因,萬一 SLBM (NC) 拒絕主機代理程式執行狀態所呈現的憑證會顯示細微資訊
PortBlocked VFP 連接埠遭到封鎖,因為缺少 VNET/ACL 原則 檢查是否有任何其他錯誤,這可能會導致原則未設定。
重載 負載平衡器 MUX 已多載 MUX 的效能問題
RoutePublicationFailure Loadbalancer MUX 未連線到 BGP 路由器 檢查 MUX 是否與 BGP 路由器連線,且 BGP 對等互連已正確設定
VirtualServerUnreachable Loadbalancer MUX 未連線到 SLB 管理員 檢查 SLBM 與 MUX 之間的連線能力
QosConfigurationFailure 無法設定 QOS 原則 如果使用 QOS 保留,請查看是否有足夠的頻寬可供所有 VM 使用

檢查網路控制器與 Hyper-V 主機 (NC 主機代理程式服務之間的網路連線)

netstat執行下列命令,以驗證 NC 主機代理程式與網路控制站節點之間有三ESTABLISHED個連線 (的) ,以及 Hyper-V 主機上的一個LISTENING套接字。

  • 在 Hyper-V 主機 (NC 主機代理程式服務上的埠 TCP:6640 上接聽)
  • 兩個已建立的連線,從埠 6640 上的 Hyper-V 主機 IP 到暫時埠上的 NC 節點 IP (> 32000)
  • 從暫時埠上的 Hyper-V 主機 IP 到埠 6640 上的網路控制站 REST IP 建立的連線

注意事項

如果該特定主機上沒有部署租使用者虛擬機,則 Hyper-V 主機上可能只有兩個已建立的連線。

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

檢查主機代理程式服務

網路控制器會與 Hyper-V 主機上的兩個主機代理程式服務通訊:SLB 主機代理程式和 NC 主機代理程式。 這些服務中有一個或兩個可能都未執行。 檢查其狀態,並在未執行時重新啟動。

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

檢查網路控制站的健康情況

如果沒有三 ESTABLISHED 個連線,或網路控制站似乎沒有回應,請使用下列 Cmdlet 檢查所有節點和服務模組是否已啟動並執行。

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

網路控制站服務模組包括:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

檢查 是否為 ReplicaStatusReady ,且 HealthStateOk

在具有多節點網路控制站的生產環境部署中,您也可以檢查每個服務主要所在的節點及其個別復本狀態。

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

檢查每個服務的複本狀態是否已就緒。

檢查網路控制器與每個 Hyper-V 主機之間的對應 HostID 和憑證

在 Hyper-V 主機上執行下列 Cmdlet,以檢查 HostID 是否對應至網路控制站上伺服器資源的實例識別碼

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

補救

如果使用 SDNExpress 腳本或手動部署,請更新登錄中的 HostId 機碼,以符合伺服器資源的實例識別碼。 重新啟動 Hyper-V 主機上的網路控制站主機代理程式 (實體伺服器) 如果使用 VMM,請從 VMM 刪除 Hyper-V 伺服器並移除 HostId 登錄機碼。 然後,再次透過 VMM 新增伺服器。

檢查 Hyper-V 主機 (主機名所使用的 X.509 憑證指紋,是否為 Hyper-V 主機 (NC 主機代理程式服務) 與網路控制器節點之間 (South) Bound 通訊的憑證主體名稱) 。 另請檢查網路控制站的 REST 憑證是否具有 主體名稱 CN=<FQDN or IP>

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

您也可以檢查每個憑證的下列參數,以確定主體名稱是主機名或 NC REST FQDN 或 IP) (預期的名稱、憑證尚未過期,以及憑證鏈結中的所有證書頒發機構單位都包含在受信任的根授權單位中。

  • 主體名稱
  • 有效期
  • 受根授權單位信任

如果 Hyper-V 主機上有多個憑證具有相同的主體名稱,網路控制站主機代理程式會隨機選擇一個憑證來呈現給網路控制站。 這可能不符合網路控制站已知之伺服器資源的指紋。 在此情況下,請刪除 Hyper-V 主機上具有相同主體名稱的其中一個憑證,然後重新啟動網路控制器主機代理程式服務。 如果仍然無法建立連線,請刪除 Hyper-V 主機上具有相同主體名稱的其他憑證,並在 VMM 中刪除對應的伺服器資源。 然後,在 VMM 中重新建立伺服器資源,這會產生新的 X.509 憑證,並將其安裝在 Hyper-V 主機上。

檢查 SLB 組態狀態

SLB 組態狀態可以決定為 Cmdlet 輸出的一 Debug-NetworkController 部分。 此 Cmdlet 也會在 JSON 檔案中輸出目前的網路控制站資源集,每個 Hyper-V 主機的所有 IP 組態 (伺服器) ,以及來自主機代理程式資料庫數據表的局域網路原則。

預設會收集更多追蹤。 若要不收集追蹤,請新增 -IncludeTraces:$false 參數。

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

注意事項

默認輸出位置將是 <working_directory>\NCDiagnostics\ 目錄。 您可以使用 -OutputDirectory 參數來變更預設輸出目錄。

您可以在此目錄的 diagnostics-slbstateResults.Json 檔案中找到 SLB 組態狀態資訊。

此 JSON 檔案可細分為下列各節:

  • 織物
    • SlbmVips - 本節列出 SLB 管理員 VIP 位址的 IP 位址,網路控制站會使用此位址來協調 SLB Mux 與 SLB 主機代理程式之間的設定和健康情況。
    • MuxState - 此區段會針對每個部署的 SLB Mux 列出一個值,以提供 Mux 的狀態
    • 路由器組態 - 本節會列出上游路由器的 (BGP 對等) 自發系統編號 (ASN) 、傳輸 IP 位址和識別符。 它也會列出SLB Muxes ASN 和傳輸IP。
    • 連線的主機資訊 - 本節會列出所有可用來執行負載平衡工作負載的 Hyper-V 主機管理 IP 位址。
    • Vip 範圍 - 本節會列出公用和私人 VIP IP 集區範圍。 SLBM VIP 會包含為其中一個範圍的已配置IP。
    • Mux 路由 - 本節會針對每個部署的 SLB Mux 列出一個值,其中包含該特定 Mux 的所有路由通告。
  • 租用戶
    • VipConsolidatedState - 本節會列出每個租使用者 VIP 的連線狀態,包括通告的路由前綴、Hyper-V 主機和 DIP 端點。

注意事項

您可以使用 Microsoft SDN GitHub 存放庫上可用的 DumpSlbRestState 腳本,直接確定 SLB 狀態。

閘道驗證

從網路控制站:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

從閘道 VM:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

從機架頂端 (ToR) 開關:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP 路由器:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

此外,從我們目前所看到的問題 (特別是 SDNExpress 型部署) ,租用戶區間未在 GW VM 上設定的最常見原因是,與嘗試指派給 TenantConfig.psd1 中網路 Connections (S2S 通道) 相比,FabricConfig.psd1 中的 GW 容量比較小。 您可以比較下列 Cmdlet 的輸出,輕鬆檢查:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster]驗證 Data-Plane

部署網路控制器之後,已建立租使用者虛擬網路和子網,且 VM 已連結至虛擬子網,主機服務提供者可以執行額外的網狀架構層級測試來檢查租用戶連線能力。

檢查 HNV 提供者邏輯網路連線能力

在 Hyper-V 主機上執行的第一個客體 VM 連線到租使用者虛擬網路之後,網路控制站會將兩個 HNV 提供者 IP 位址 (PA IP 位址) 指派給 Hyper-V 主機。 這些IP會來自 HNV 提供者邏輯網路的IP集區,並由網路控制站管理。 若要瞭解這兩個 HNV IP 位址是什麼:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

這些 HNV 提供者 IP 位址 (PA IP) 會指派給在個別 TCPIP 網路區間中建立的乙太網路適配器,並具有 VLANX 的適配卡名稱,其中 X 是指派給 HNV 提供者 (傳輸) 邏輯網路的 VLAN。

使用 HNV 提供者邏輯網路的兩部 Hyper-V 主機之間的連線,可以透過具有額外區間的 ping (-c Y) 參數來完成,其中 Y 是建立 PAhostVNIC 的 TCPIP 網路區間。 您可以執行下列動作來判斷此區間:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

注意事項

PA 主機 vNIC 配接器不會用於數據路徑中,因此沒有指派給「vEthernet (PAhostVNic) 配接器」的 IP。

例如,假設 Hyper-V 主機 1 和 2 具有 HNV 提供者 (PA) IP 位址:

Hyper-V 主機 PA IP 位址 1 PA IP 位址 2
主機 1 10.10.182.64 10.10.182.65
主機 2 10.10.182.66 10.10.182.67

我們可以使用下列命令在兩者之間偵測,以檢查 HNV 提供者邏輯網路連線能力。

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

補救

如果 HNV 提供者 ping 無法運作,請檢查您的實體網路連線能力,包括 VLAN 設定。 每個 Hyper-V 主機上的實體 NIC 應處於主幹模式,且未指派特定 VLAN。 管理主機 vNIC 應該與管理邏輯網路的 VLAN 隔離。

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

檢查 HNV 提供者邏輯網路上的 MTU 和 Jumbo 框架支援

HNV 提供者邏輯網路的另一個常見問題是實體網路埠和/或乙太網路卡沒有設定為足以處理來自 VXLAN (或 NVGRE) 封裝額外負荷的 MTU。

注意事項

某些乙太網路卡片和驅動程序支援新的 *EncapOverhead 關鍵詞,網路控制器主機代理程式會自動將它設定為160的值。 這個值接著會新增至 *JumboPacket 關鍵詞的值,其總和會做為通告的 MTU 使用。

例如, *EncapOverhead = 160 和 *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

若要測試 HNV 提供者邏輯網路是否支援較大的 MTU 大小端對端,請使用 Test-LogicalNetworkSupportsJumboPacket Cmdlet:

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

補救

  • 將實體交換器埠上的 MTU 大小調整為至少 1674B (包括 14B 乙太網路標頭和預告片)
  • 如果您的 NIC 記憶卡不支援 EncapOverhead 關鍵詞,請將 JumboPacket 關鍵詞調整為至少 1674B

檢查租使用者 VM NIC 連線能力

指派給客體 VM 的每個 VM NIC,在私人客戶位址 (CA) 與 HNV 提供者位址 (PA) 空間之間都有 CA-PA 對應。 這些對應會保留在每個 Hyper-V 主機上的 OVSDB 伺服器數據表中,並可藉由執行下列 Cmdlet 來找到。

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

注意事項

如果您預期的 CA-PA 對應不是指定租使用者 VM 的輸出,請使用 Get-NetworkControllerNetworkInterface Cmdlet 檢查網路控制站上的 VM NIC 和 IP 組態資源。 此外,請檢查 NC 主機代理程式與網路控制站節點之間已建立的連線。

有了這項資訊,主機服務提供者現在可以使用 Test-VirtualNetworkConnection Cmdlet 從網路控制站起始租使用者 VM Ping。

特定疑難解答案例

下列各節提供針對特定案例進行疑難解答的指引。

兩部租用戶虛擬機之間沒有網路連線

  1. [租使用者]確定租用戶虛擬機中的 Windows 防火牆不會封鎖流量。
  2. [租使用者]執行 ,檢查是否已將IP位址指派給租使用者虛擬機 ipconfig
  3. [Hoster] Test-VirtualNetworkConnection 從 Hyper-V 主機執行 ,以驗證有問題的兩個租使用者虛擬機之間的連線。

注意事項

VSID 是指虛擬子網標識碼。 在 VXLAN 的案例中,這是 VNI) (VXLAN 網路識別碼。 您可以執行 Cmdlet 來 Get-PACAMapping 找到此值。

範例

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

在主機 「sa18n30-2.sa18.nttest.microsoft.com」 上,使用 SenderCA IP 為 192.168.1.4 的 “Green Web VM 1” 與 Mgmt IP 為 10.127.132.153 的 Mgmt IP 與 192.168.1.5 的 ListenerCA IP 建立 CA-ping,這兩者都已連結至虛擬子網 (VSID) 4114。

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[租使用者]檢查虛擬子網或 VM 網路介面上沒有指定任何會封鎖流量的分散式防火牆原則。

查詢在示範環境中找到的網路控制器 REST API,位於 sa18.nttest.microsoft.com 網域中的 sa18n30nc。

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

查看參考此 ACL 的IP組態和虛擬子網

  1. [Hoster] Get-ProviderAddress 在裝載有問題的兩部租使用者虛擬機的兩部 Hyper-V 主機上執行 ,然後 Test-LogicalNetworkConnection 從 Hyper-V 主機執行 或 ping -c <compartment> ,以驗證 HNV 提供者邏輯網路上的連線能力
  2. [Hoster]請確定 Hyper-V 主機上的 MTU 設定正確,以及 Hyper-V 主機之間的任何第 2 層切換裝置。 在 Test-EncapOverheadValue 所有有問題的 Hyper-V 主機上執行。 此外,請檢查 之間的所有第 2 層切換都已將 MTU 設定為至少 1674 個字節,以考慮 160 個字節的最大額外負荷。
  3. [Hoster]如果 PA IP 位址不存在,且/或 CA 連線中斷,請檢查以確定已收到網路原則。 執行 Get-PACAMapping 以查看是否已正確建立建立重疊虛擬網路所需的封裝規則和 CA-PA 對應。
  4. [Hoster]檢查網路控制站主機代理程式是否已連線到網路控制站。 若要這樣做,請執行 netstat -anp tcp |findstr 6640
  5. [Hoster]檢查 HKLM/ 中的主機標識碼是否符合裝載租使用者虛擬機之伺服器資源的實例識別碼。
  6. [Hoster]檢查埠配置檔識別碼是否符合租用戶虛擬機之 VM 網路介面的實例識別碼。

記錄、追蹤和進階診斷

下列各節提供進階診斷、記錄和追蹤的相關信息。

網路控制站集中式記錄

網路控制器可以自動收集調試程序記錄,並將其儲存在集中位置。 當您第一次或之後部署網路控制站時,可以啟用記錄收集。 記錄會從網路控制站收集,以及網路控制站所管理的網路元素:主計算機、軟體負載平衡器 (SLB) 和閘道機器。

這些記錄包括網路控制站叢集、網路控制站應用程式、閘道記錄、SLB、虛擬網路和分散式防火牆的偵錯記錄。 每當新的主機/SLB/閘道新增至網路控制站時,就會在這些電腦上啟動記錄。 同樣地,當主機/SLB/閘道從網路控制站移除時,這些電腦上的記錄就會停止。

啟用記錄

當您使用 Cmdlet 安裝網路控制站叢集時, Install-NetworkControllerCluster 會自動啟用記錄。 根據預設,記錄會在 位於 %systemdrive%\SDNDiagnostics 的網路控制站節點本機上收集。 建議您將此位置變更為遠端檔案共用, (不是本機) 。

網路控制站叢集記錄會儲存在 %programData%\Windows Fabric\log\Traces。 您可以使用 參數來指定記錄收集 DiagnosticLogLocation 的集中式位置,並建議這也是遠端檔案共用。

如果您想要限制此位置的存取,您可以使用 參數提供存取認證 LogLocationCredential 。 如果您提供認證來存取記錄位置,您也應該提供 CredentialEncryptionCertificate 參數,以用來加密儲存在網路控制站節點本機的認證。

使用預設設定時,建議您在中央位置至少有 75 GB 的可用空間,如果未針對三節點網路控制器叢集使用中央位置) ,則本機節點上應至少有 25 GB 的可用空間 (。

變更記錄設定

您可以隨時使用 Set-NetworkControllerDiagnostic Cmdlet 變更記錄設定。 您可以變更下列設定:

  • 集中式記錄檔位置。

    您可以使用 參數來變更儲存所有記錄 DiagnosticLogLocation 的位置。

  • 存取記錄位置的認證。

    您可以使用 參數來變更認證以存取記錄位置 LogLocationCredential

  • 移至本機記錄。

    如果您已提供集中式位置來儲存記錄,則可以移回網路控制器節點 UseLocalLogLocation 上的本機記錄,因為) 磁碟空間需求很大,因此不建議使用 參數 (。

  • 記錄範圍。

    根據預設,會收集所有記錄。 您可以變更範圍,只收集網路控制站叢集記錄。

  • 記錄層級。

    默認記錄層級為 Informational。 您可以將它變更為 [錯誤]、[警告] 或 [詳細資訊]。

  • 記錄過時時間。

    記錄會以迴圈方式儲存。 您預設會有三天的記錄數據,不論您是使用本機記錄或集中式記錄。 您可以使用 參數來變更此時間限制 LogTimeLimitInDays

  • 記錄過時大小。

    根據預設,如果使用集中式記錄,您最多會有 75 GB 的記錄數據,如果使用本機記錄,則會有 25 GB 的記錄數據。 您可以使用 參數來變更此限制 LogSizeLimitInMBs

收集記錄和追蹤

VMM 部署預設會使用網路控制站的集中式記錄。 部署網路控制站服務範本時,會指定這些記錄的檔案共用位置。

如果尚未指定檔案位置,則會在每個網路控制站節點上使用本機記錄,並將記錄儲存在 C:\Windows\tracing\SDNDiagnostics 底下。 這些記錄會使用下列階層來儲存:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • 痕跡

網路控制器會使用 (Azure) Service Fabric。 針對特定問題進行疑難解答時,可能需要 Service Fabric 記錄。 您可以在 C:\ProgramData\Microsoft\Service Fabric 的每個網络控制站節點上找到這些記錄。

如果使用者已執行 Cmdlet Debug-NetworkController ,則每個 Hyper-V 主機上會提供更多記錄,而該主機已使用網路控制器中的伺服器資源來指定。 如果啟用) 保留在 C:\NCDiagnostics 底下,這些記錄 (和追蹤。

SLB 診斷

裝載服務提供者動作 (SLBM 網狀架構錯誤)

  1. 檢查軟體 Load Balancer 管理員 (SLBM) 是否正常運作,且協調流程層可以彼此通訊:SLBM -> SLB Mux 和 SLBM -> SLB 主機代理程式。 從任何可存取網路控制站 REST 端點的節點執行 DumpSlbRestState
  2. 在其中一個網路控制站節點 VM 上驗證 PerfMon 中的 SDNSLBMPerfCounters (最好是主要網路控制站節點 - Get-NetworkControllerReplica) :
    1. Load Balancer (LB) 引擎是否已連線到 SLBM? (SLBM LBEngine 設定總計 > 0)
    2. SLBM 至少知道自己的端點嗎? (VIP 端點總計>= 2)
    3. Hyper-V (DIP) 主機是否已連線到 SLBM? (HP 用戶端已連線 == num 伺服器)
    4. SLBM 是否已連線到 Mux? (Mux connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM) 。
  3. 確定已設定的 BGP 路由器已成功與 SLB MUX 對等互連。
    1. 如果使用 RRAS 搭配遠端存取 (即 BGP 虛擬機器) :
      1. Get-BgpPeer 應該會顯示已連線。
      2. Get-BgpRouteInformation 應該至少顯示 SLBM 自我 VIP 的路由。
    2. 如果使用實體機架頂端 (ToR) 切換為 BGP 對等互連,請參閱您的檔:
      1. 例如:# show bgp instance
  4. 驗證 SLB Mux VM 上 PerfMon 中的 SlbMuxPerfCounters 和 SLBMUX 計數器。
  5. 檢查軟體 Load Balancer 管理員資源中的設定狀態和VIP範圍。
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (檢查 IP 集區中的 VIP 範圍,並確保 SLBM 自我 VIP (LoadBalanacerManagerIPAddress) ,且任何面向租使用者的 VIP 都在這些範圍內)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

如果上述任何檢查失敗,租使用者 SLB 狀態也會處於失敗模式。

補救

根據所呈現的下列診斷資訊,修正下列問題:

  • 確定 SLB 多任務器已連線
    • 修正憑證問題
    • 修正網路連線問題
  • 確定已成功設定 BGP 對等互連資訊
  • 請確定登錄中的主機標識碼符合伺服器資源中的伺服器實例標識碼 (參照 HostNotConnected 錯誤碼的附錄)
  • 收集記錄

裝載服務提供者和租用戶動作 (SLBM 租使用者錯誤)

  1. [Hoster]檢查 Debug-NetworkControllerConfigurationState 是否有任何 LoadBalancer 資源處於錯誤狀態。 請遵循附錄中的動作專案表格,嘗試減輕此問題。
    1. 檢查VIP端點是否存在,並公告路由。
    2. 檢查已探索到VIP端點的 DIP 端點數目。
  2. [租使用者]驗證 Load Balancer 正確指定資源。
    1. 驗證在 SLBM 中註冊的 DIP 端點裝載租用戶虛擬機,其對應於 LoadBalancer 後端位址池 IP 組態。
  3. [Hoster]如果未探索或連線 DIP 端點:
    1. 檢查 Debug-NetworkControllerConfigurationState

      使用驗證 NC 和 SLB 主機代理程式已成功連線到網路控制器事件協調器 netstat -anp tcp |findstr 6640)

    2. HostIdnchostagent 服務 regkey (附錄) 中的參考 HostNotConnected 錯誤碼符合對應伺服器資源的實例標識碼 (Get-NCServer |convertto-json -depth 8) 。

    3. 檢查虛擬機器埠的埠配置檔標識碼是否符合對應的虛擬機 NIC 資源實例識別碼。

  4. [主控提供者]收集記錄。

SLB Mux 追蹤

軟體 Load Balancer Mux 的資訊也可以透過 事件檢視器 來判斷。

  1. 取 [事件檢視器檢視] 功能表下的 [顯示分析和偵錯記錄]。
  2. 流覽至 事件檢視器 中的應用程式和服務記錄>Microsoft>Windows>SlbMuxDriver>追蹤
  3. 以滑鼠右鍵按兩下它,然後選 取 [啟用記錄]

注意事項

當您嘗試重現問題時,建議您只在短時間內啟用此記錄。

VFP 和 vSwitch 追蹤

從裝載連接至租使用者虛擬網路之客體 VM 的任何 Hyper-V 主機,您可以收集 VFP 追蹤,以判斷問題可能出在哪裡。

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes